home *** CD-ROM | disk | FTP | other *** search
/ Kirk's Comm Disc 1995 December / Kirk's Comm Disc - Version 2.iso / dos / fido / ftsc_all.z43 / FSC-0036.TXT < prev    next >
Text File  |  1989-06-27  |  13KB  |  267 lines
  1. FSC-0036
  2.  
  3.                          GROUP MAIL SPECIFICATIONS
  4.                              by Dale W. Lovell
  5.                               7:41/34@alternet
  6.                              1:157/504@fidonet
  7.  
  8. Group Message Files
  9.  
  10. A Group  Message File is  a file which  contains messages for  a particular
  11. group conference. The file is named as follows:
  12.  
  13.      <id>.xxx
  14.  
  15. Where:
  16.      <id> is the GroupMail ID name
  17.      xxx  is the minute of the month that  the last packet was added to the
  18.           file in base  36 (0..9,A..Z).  The following  extensions are  NOT
  19.           used ARC, BAT,  COM, DOC, EXE, PKT,  TXT. If a packet  is created
  20.           would normally have this name,  the minute is "bumped up" one  to
  21.           avoid using  these names.  (This is  also the  extension used  by
  22.           ARCmail).
  23.  
  24. Each file can contain several packets of messages. Packets should be in the
  25. Fido type 2  packet. The packets start  off with a packet  header. Messages
  26. follow  the  packet header.  Each message  starts  off with  an abbreviated
  27. packetized message header. Following the header are several variable length
  28. fields. The structures is as follows:
  29.  
  30.      struct pkthdrs {              /* packet header structure */
  31.           int ph_onode;            /* Originating node number */
  32.           int ph_dnode;            /* Destination node number */
  33.           int ph_yr,ph_mo,ph_dy;   /* Date packet was assembled */
  34.           int ph_hr,ph_mn,ph_sec;  /* Time packet was assembled */
  35.           int ph_rate;             /* packet baud rate */
  36.           int ph_ver;              /* packet version */
  37.           int ph_onet;             /* Originating net */
  38.           int ph_dnet;             /* destination net */
  39.           int ph_rsvd[17];         /* Reserved for possible future use */
  40.           };
  41.  
  42.      struct pktmsgs {              /* packetized message headers */
  43.           int pm_ver;              /* message version */
  44.           int pm_onode;            /* Originating node */
  45.           int pm_dnode;            /* Destination node */
  46.           int pm_onet;             /* Originating net */
  47.           int pm_dnet;             /* Destination net */
  48.           int pm_attr;             /* Message attributes */
  49.           int pm_cost;             /* message cost in cents */
  50.           };
  51.  
  52. The variable length data that follows is:
  53.      Field Description             Maximum length (in characters)
  54.           Date                          20
  55.           To whom                       36
  56.           Who From                      36
  57.           Subject                       72
  58.           Message text                  8192
  59.  
  60. The packet is finished when in place of the packetized message header there
  61. are two null characters.
  62.  
  63. Message Attributes
  64.  
  65. Message  headers  contain an  integer  field holding  "message attributes."
  66. These are bit  values that select various  properties of the  message. They
  67. are defined as follows:
  68.  
  69.      #define MSGPRIVATE  0x0001    /* Private message */
  70.      #define MSGCRASH    0x0002    /* Crash priority message */
  71.      #define MSGREAD     0x0004    /* Read by addressee */
  72.      #define MSGSENT     0x0008    /* Sent okay */
  73.      #define MSGFILE     0x0010    /* file attached */
  74.      #define MSGFWD      0x0020    /* being forwarded */
  75.      #define MSGORPHAN   0x0040    /* Unknown destination */
  76.      #define MSGKILL     0x0080    /* Kill after mailing */
  77.      #define MSGLOCAL    0x0100    /* True if message entered here */
  78.      #define MSGHOLD     0x0200    /* true if hold for pickup */
  79.      #define MSGX2       0x0400    /* reserved -- sent */
  80.      #define MSGFREQ     0x0800    /* Requesting a file */
  81.      #define MSGRREQ     0x1000    /* Return Receipt requested */
  82.      #define MSGRRCT     0x2000    /* Return Receipt */
  83.      #define MSGAREQ     0x4000    /* Request audit trail */
  84.      #define MSGUREQ     0x8000    /* Requesting a file update */
  85.  
  86. The following attribute bits are included in the packetized message header.
  87.  
  88.      MSGPRIVATE     MSGFILE   MSGCRASH  MSGX2     MSGRREQ
  89.      MSGRRCT        MSGAREQ
  90.  
  91. All other attributes are masked off and are not sent to other systems.
  92.  
  93. Packet files names are as follows:
  94.  
  95.      ddhhmmss.PKT
  96.  
  97. Where:
  98.      dd   is the day of the month the packet was created
  99.      hh   is the hour (24 hour clock) the packet was created
  100.      mm   is the minute the packet was created
  101.      ss   is the second the packet was created
  102.  
  103. For example if a GroupMail file in the conference SAMPLE is  created on the
  104. 22nd of a month at 08:15 the Groupmail name would be SAMPLE.NPR.
  105.  
  106.           21 full days                  8.25 hours
  107.      x  1440 minutes per day       x      60 minutes per hour
  108.      -------                       ---------
  109.        30240 minutes                     495 minutes
  110.      +   495 minutes in today
  111.      -------
  112.        30735 minutes into the month     Convert to base 36: NPR
  113.  
  114. Note that at most there are 44640 minutes in a month and this naming scheme
  115. has the capability  to handle up to  46656 file names. The  remaining names
  116. (2015 files or an average of 65 files per day) may be used for distributing
  117. other files in a conference (anything over YG0, hint if it starts with Z it
  118. makes it easy  to identify, still leaves 1296 different files or average of
  119. 41 files per day).
  120.  
  121. Disk Directories
  122.  
  123. GroupMail  uses two  special directories for  distributing it's  files. The
  124. first of  these directories contains  what I will  be calling a  group date
  125. file  and any unprocessed,  inbound group files.  The Group Date  File is a
  126. zero length file in the format:
  127.  
  128.      <id>.!
  129.  
  130. Where:
  131.      <id> is the Group conference name
  132.  
  133. When new files  are update requested, the  mailer should only obtain  those
  134. files whose time/date stamps are later than this file's time/date stamp (or
  135. any unprocessed group files with a later time/date stamp).
  136.  
  137. This directory will be referred to as the Group Inbound Directory.
  138.  
  139. If a  system is holding  any conferences for  others to update  request, it
  140. will need another directory. This directory  holds all processed Group Mail
  141. Files.  These files  can be  held for  up to  31 days.  After a  file whose
  142. conference is  being held for  others is processed,  it should be  moved to
  143. this directory. This  move MUST leave the  time/date stamp as it  was. If a
  144. system deviates this for ANY reason WOE unto they who wrote  the Group Mail
  145. processor.  This  directory  will  be  referred  to as  the  Group  Holding
  146. Directory.
  147.  
  148. Message files
  149.  
  150. In theory  (and  almost always  in practice)  you can  store the  processed
  151. messages in  any format  you desire.  New messages  must be  put into  your
  152. network mail area as a message your mailer can handle and send  properly to
  153. other Fido compatible  bulletin board systems/mailers.  The structure of  a
  154. Fido message is as follows:
  155.  
  156.      struct msghdrs {              /* Message header structure */
  157.           char m_from[36];         /* Who from */
  158.           char m_to[36];           /* to whom */
  159.           char m_subj[72];         /* subject of message */
  160.           char m_date[20];         /* Date of message */
  161.           int  m_times;            /* Number of times read */
  162.           int  m_dnode;            /* Destination node */
  163.           int  m_onode;            /* Originating node */
  164.           int  m_cost;             /* Cost of message in cents */
  165.           int  m_onet;             /* Originating net */
  166.           int  m_dnet;             /* Destination net */
  167.           int  m_caca;             /* extra space */
  168.           int  unsigned m_rep;     /* Thread to previous */
  169.           int  m_attr;             /* Message attributes */
  170.           int  m_up;               /* Thread to next */
  171.           };
  172.  
  173. The header is followed by the text of the message. This text is stored as a
  174. string of characters ending  with a null. The  text may or may  not contain
  175. carriage returns, each  of which may or may not be  followed by a linefeed.
  176. Any of  these carriage returns may be "soft."  If the high order bit (0x80)
  177. of the carriage  return is set,  then it is a  soft return. Line  feeds and
  178. soft returns should be ignored.
  179.  
  180. More on the actual messages later on.
  181.  
  182. Processing inbound messages
  183.  
  184. For conferences where you are NOT the top star
  185.  
  186. Unprocessed  Group  Message Files  are in  the  Group Inbound  Directory. A
  187. processor should go through  all Group Message Files which  are conferences
  188. that the  system actually caries  (as opposed to  just passing  through for
  189. other  systems). The  file's name  should  be used  to determine  for which
  190. conference  these messages  are  destined. While  most processors  have the
  191. first line  of text  read as  ^AAREA:<id> (no  spaces), this  is meant  for
  192. compatibility to those systems which do not yet have GROUP capabilities. In
  193. short, YOU  CAN NOT  DEPEND ON IT  BEING THERE,  so USE  THE FILENAME.  The
  194. packets should  be extracted from the archived  message file, put into your
  195. message  base. The packet files  should then be  deleted. Messages put into
  196. your message base from these Group  Message Files should be marked in  some
  197. way so  that they are not processed as  newly entered messages. SEA's GROUP
  198. utility uses the  message sent flag for  this purpose and we  recommend the
  199. use of the same flag wherever possible.
  200.  
  201. After  all Group  Message Files have  been processed, the  Group Date Files
  202. should have their time/date stamp changed  to that of the most recent  file
  203. processed. Any Group  Message Files  for conferences being  held for  other
  204. systems should be moved to the Group Holding Directory so other systems can
  205. request these files.  When the Group  Message File is moved,  the time/date
  206. stamp on the file MUST NOT be changed. Group Message Files  for conferences
  207. not being held for others should be deleted.
  208.  
  209. It is also desirable  at this time to delete any Group  Message Files which
  210. are over one month old, or whatever period of time  less than one month the
  211. system operator of that board desires.
  212.  
  213. For conferences where you ARE the top star
  214.  
  215. You  should check for  any new netmail  messages whose  ^AAREA:<id> line is
  216. "your" conference ID. These  messages should be imported into  your message
  217. base with  the message sent  flag (or your  own equivalent) turned  OFF. At
  218. such a time as you "PACK" new Group Message Files you should turn the  sent
  219. flag ON. 
  220.  
  221. Processing new outbound messages
  222.  
  223. For conferences where you ARE NOT the top star
  224.  
  225. Your  group  processor should  scan through  all  group conferences  on the
  226. system and  locate any  messages which  have been  entered. These  messages
  227. should be prepared to be sent  out via network mail. The first line  of the
  228. network mail message should read:
  229.  
  230.      ^AAREA:<id>
  231.  
  232. Where:
  233.      <id> is the Group conference name
  234.  
  235. There should be no spaces in  this area, although your processor should  be
  236. tolerant of any spaces if they are present.
  237.  
  238. The message should be "from" your address and addressed to your upward link
  239. in  the  conference. In  addition  the  message  should  be  marked  to  be
  240. deleted/killed after being sent.
  241.  
  242. You should also  check to  see if any  messages in  your netmail area  from
  243. other systems are for a GroupMail conference (either one you carry, or pass
  244. on to other systems). Any of  these messages should be readdressed to  your
  245. upward link in the conference. Under no circumstances should you change the
  246. from fields, they should contain the address  of the person who entered the
  247. message into the conference.
  248.  
  249. For conferences where you ARE the top star
  250.  
  251. Messages should  be "copied" from your  message base into a  properly named
  252. Group Message File. This  Group Message File must have a  correct time/date
  253. stamp and  be in  your Group  Holding Directory.  Once a  message has  been
  254. copied into a  Group Message File, it is  necessary to mark it  so the same
  255. message is not placed into another Group Message File. SEA's GROUP uses the
  256. message sent flag  for this purpose and  we recommend the  use of the  same
  257. flag whenever possible.
  258.  
  259. I think that's it.  Everything else is handled by your  mailer. In order to
  260. get new  Group Mail  messages, you do  a file  update request of  the GROUP
  261. conference name (<id>.*)  with the  update pointing to  your Group  Inbound
  262. Directory. Your mailer  will then get any new Group Message Files from your
  263. upward link in  the conference. As new  Group Message Files are  processed,
  264. those who are obtaining their conferences from you will perform file update
  265. requests from your Group Holding Directory.
  266.  
  267.